プロダクトのリリースとGitブランチ運用を考えてみた
プロダクト開発とリリースは切っても切れない関係にあります。そしてプロダクトはGitなどでバージョン管理しているでしょう。 本記事では、とあるプロダクトを例として、リリースを絡めたGitブランチ運用をご紹介します。
おすすめの方
- Gitブランチ運用について、参考にした方
前提
- スクラムで開発しています
- 1スプリントは1週間です
プロダクトの環境は4つ
目的に合わせて4つの環境があります。
| 環境名 | 位置づけ |
|---|---|
| 開発環境 | 開発チームが開発するための環境 |
| レビュー環境 | レビューするための環境 |
| ステージング環境 | 本番同様に使ってテストする環境 |
| 本番環境 | エンドユーザが使う環境 |
詳細は下記をご覧ください。
Gitブランチ運用
Git FlowとGitHub Flow
Gitのブランチ運用としては、Git FlowやGitHub Flowがよく用いられます。Git Flowはプロダクトやチームの規模に対して過剰かつ複雑と判断し、GitHub Flowを少しだけアレンジしたGit運用を行います。
求めるポイント
GitHub Flowに対して追加で求めるポイントは、ステージング環境と本番環境へのリリースタイミングを自分たちでコントロールしたいです。理由は下記です。
- プロダクトオーナーのOKが出たモノだけをステージング環境と本番環境にリリースしたい
- 「masterブランチにマージされたらすぐに本番環境にデプロイ」は都合が悪い
- リリース頻度は1週間に1回ぐらいなので、masterブランチへのマージを手動Stopするのは都合が悪い
これらについてアレンジしています。
考えたGitブランチ運用
「開発環境とレビュー環境へのデプロイ」と「ステージング環境と本番環境へのデプロイ」のトリガーを分けます。具体的には、「ステージング環境と本番環境へのデプロイ」は、タグのPushで動くようにします。大まかな作業の流れは下記です。
- masterブランチを主体とする（GitHub Flow）
- 実装等を行う際は、masterブランチから実装用ブランチを作成して作業する
- 実装用ブランチにpushしたとき、開発環境にデプロイされる
- 実装用ブランチからプルリクエストを出し、masterブランチにマージする
- masterブランチにマージされたら、開発環境とレビュー環境にデプロイされる
- タグをpushしたとき、ステージング環境と本番環境にデプロイされる
デメリット
下記のデメリットがあります。
- 他人がブランチをpushしたとき、開発環境がその内容に更新されてしまう（後勝ちのため、自分がpushした内容が上書きされる）
- 対策1：諦める。pushする前に「他人がpushしてないか確認する。pushしている場合は、pushしてよいか確認する
2-3人の少人数チーム、かつ、ローカルでテストできる環境があるため成り立っている側面は大きいと思います。
CI/CDのワークフロー
ワークフローは3種類の動作を行います。
| コミット場所 | ワークフローの動作 |
|---|---|
| masterブランチ | 開発環境とレビュー環境にデプロイ |
| masterブランチ以外 | 開発環境にデプロイ |
| vx.y.zタグ | ステージング環境と本番環境にデプロイ |
「開発環境からレビュー環境」および「ステージング環境から本番環境」は、Approve機能を用いて人間が承認することで進むようにします。
各環境へのデプロイを直列ではなく並列にしている理由は、下記をご覧ください。
具体的な例
実装時のブランチ
masterブランチから作業用ブランチを作成し、コミットしていきます。
この状態で作業用ブランチをPushすると、開発環境にデプロイするワークフローが実行されます。
プルリクをmasterにマージした
作業ブランチからmasterブランチに対するプルリクを作成し、承認されてmasterブランチにマージされた状態です。
この状態では、開発環境とレビュー環境にデプロイするワークフローが実行されます。
レビュー環境へのデプロイにApproveを設けている理由は、あるストーリーを複数のプルリクに分割して実装しているとき、レビューに間に合わない中途半端な状態がレビュー環境にデプロイされたくないためです。レビューするに値する状態のプロダクトをレビュー環境に維持したいのです。
リリースする
タグを付けてリリースを行います。タグは任意の地点に付けることができます。
タグをPushすると、ステージング環境と本番環境にデプロイするワークフローが実行されます。
不具合があったので緊急対応する
リリース済みのv1.1.0に不具合が発覚し、急遽対応することになりました。
v1.1.0から対応ブランチを作成し、対応します。
プルリクを出してチームメンバーに確認してもらい、masterブランチにマージします。
緊急対応した内容を緊急リリースする
このままmasterブランチをリリースすると、issues/2ブランチの内容も含まれてしまいます。それは嬉しくないため、issues/2ブランチを含まない場所にv1.1.1のタグを付けます。
v1.1.1のタグをpushすることで、ステージング環境と本番環境にデプロイするワークフローが実行されます。
さいごに
さまざまなGitのブランチ運用があると思います。何かの参考になれば幸いです。
